Summary

Optimizes buffer management in renderToAsyncIterable for streaming SSR. This is a follow-up to #15605 which focused on the render loop itself — this PR targets the buffer/encoding layer.

What changed

The write() method in renderToAsyncIterable now accumulates string chunks into a currentString variable during the write phase, only encoding to Uint8Array when a non-string chunk arrives or when next() is called. This replaces the previous approach of pushing mixed string | Uint8Array into the buffer and then rescanning + merging in next().

Before: next() iterated the buffer to find consecutive strings, concatenated them, encoded them, then did a second pass to merge all Uint8Arrays. This was O(N²) in the number of string chunks due to the rescan.

After: Strings are concatenated during write() (O(1) per call), and next() sees a buffer of only Uint8Array entries — just measure total length and copy. One TextEncoder.encode() call per flush instead of one per string-group.

Benchmark results (vs main)

Non-streaming paths are unaffected (they don't use renderToAsyncIterable).

What was tested and discarded

Three other optimizations were benchmarked individually and in combination during development:

1. Lazy Promise Wrapping — deferred promiseWithResolvers creation in the render loop. Hurt streaming component throughput by ~9%.
2. Direct Promise Usage in BufferedRenderer — caused regressions.
3. String Fast-Path in renderChild — caused regressions.

Only the buffer optimization (this PR) showed consistent improvement across all streaming benchmarks.